BBS in a Box 5/BBS in a Box -Volume V (BBS in a Box) (April 1992).iso/Files/Tele/H/Host2.0 Suggestions

Text File | 1987-11-27 | 14.0 KB | 259 lines | [TEXT/MSWD]

First off a few things about the following list.  It is a "condensation" of the
conversations concerning Host and what various people would like to see in
Host V2.0 some are unaltered and some are composites of several views and some
are my ideas.  Note that this is a compression of about 700K of messages down
to 14K so if I didn't cover your "pet suggestion" sorry add it to the new topic
covering suggestions of items to add to Host V2.0
Also I have divided the items up into what seemed to be logical assignments as
to where the item would need to be addressed which may or may not be valid
other than that there is no particular order to the items.

System (Host)

1    All system messages configureable (<CR> instead of <N>ext etc.)
2    Multi-line support, either thru the modem & printer ports, or a card
    for the SE & MacII, or a box hooked to the SCSI port, or thru multiple
    Macs on a network, Host running twice under the new "multi-tasking"
    system (somehow enable a multi-user host system)
3    Login stats that could be stored in the config file that shows and
    maintains the number of calls that the BBS has recorded that day, and
    a total number of calls since the system went online. (also see 1)
4    Complete configurablity of the "Stat's at log-on" option (see 1)
5    On menu bar where it shows the last person on, add when they were on
6    Extend or freeze user's elapsed time when in chat mode (I've dropped a
    user right after chatting due to having used up their time chatting)
7    2400/9600 baud, MNP (Microcom Networked Protocol).  MNP is becoming a
    "must-include" item for 2400-bps and faster modems.
8    YModem/YModem-G...YModem is pretty standard in the MS-DOS realm.
    YModem-G is a must for MNP.
9    ANSI Graphics support  (for MS-DOS/VAX/etc)
10    Color Support (for MS-DOS/Mac II)
11    Ability for the Sysop to incorporate "EVENTS".  An event would be
    a "Sysop-defineable" time when the BBS would send a command to the
    modem to go off-hook (ATH1), launch another program (say...Red Ryder)
    and perform a task (log-on GEnie and read your mail).  After the
    event, the system would re-launch and again accept calls from users.
    Events could include remapping of time limits, open/close access to
    online games, upload/download files on another system, etc.
12    Alternate definable path function at logon i.e. a forced new user
    survey or a "Forced read mail message" to an individual etc.
13    Support some sort of robust and efficient communication protocol for
    file transfer. For example, the uucp protocol would be nice.
14    Menu bar indicator whether there is any mail for the sysop.



Menu's

15    Two message lines per command line so that you can have <X>pert,
    <T>erse, and <V>erbose command lines (only one would show at a time,
    and the menu manager should be configurable as to whether you wanted
    to use 1 or 2 lines)
16    Range of Security Levels per command vs the <=, =, >= options currently
    available, with logical operators & (and), ! (nor), - (range) = as in
    10&20 means 10 and 20 have access, 10!20 means 10 nor 20 have access,
    and 10-200 means 10 thru 200 have access
    if second security byte added 10=20 user must be 10,20 (see 51)
17    Allow multiple RRHost actions per command key. For example, output a
    text file, and then switch menus.
18    Add parameters to menu invocations. Many file section and message
    section menus are identical other than the header and the optional data
    on some commands.  Allowing symbolic replacement of these fields with
    provision for symbol definition would allow sharing of common menu
    structure.


Libraries

19    While the current version of Host allows unlimited File Sections, each
    one is limited to 300± listings (should be limited only by file name
    length, 12 to the 36th power) 12 character file name using A-Z, 0-9, .
20    File sections should count file accesses to more easily determine which
    files can be removed and never missed.
21    Global file section searches.  (If the file sections were built into
    one relational data base this would be easy)
22    File names longer than 12 characters.  Nice but not really needed if
    the file type descriptions were configurable (freeing the last four
    characters from having to carry ".xxx" file type codes) giving an
    effective file name length of 16 characters.
23    Descriptions longer than 60 characters, possibly 3-75 character lines
    for a description (configurable)
24    Built-in remote file section commands to delete not only a listing, but
    the file as well from the disk, as well as editing of File names and
    descriptions remotely.
25    Library, more than four file type categories, Packit as one instance.
26    Filenames of at least 16-24 characters, and description fields of up to
    210 characters (about 3 70 character lines), that should allow a user
    to accurately describe the file and the format that it was uploaded in.
27    Longer descriptions...or possibly use a method like GEnie...have the
    60 character description and allow longer descriptions that can be
    viewed if requested.
28    The "find/search" filenames option extended to include searching of
    file descriptions in addition to filenames.
29    Configurable Maximum File size to allow on uploads.



Message Sections

30    Configurable maximum message length
31    UpLoads allowed to message sections
32    Private mail, either forced delete after reading or flagged as read for
    later deletion, should be selective so that the sysop can keep his/her
    own mail if desired
33    User command to wipe the text body of a message rather than wiping
    everything (including address, & header line)
34    A search on the subject line of the message base command
35    Chaining of messages with appropriate read/scan commands
36    File attached to message facility.  Sender & receiver must be able to
    delete the file from disk.
37    another possible command for the message sections, a command that will
    prompt you for a word or search string, then search the message base
    for that word or string. It would come in handy for locating messages
    that are on unigue subjects, or following a variety of threads on a
    certain subject.....It could be setup to either work in the existing
    section or globally across all sections and then report possible
    matches or take you to each message with that criteria until you locate
    the message in question
38    Forced time-out during message section reads (with notice sent X
    minutes ahead of time instead of just dropping them)
39    Move messages from one section/topic thread to another
40    It's been said before, but the ability to read the previous message-
    -that is the one to which a reply is replying to- -would be wonderful.
    Instead of decoding messages that say "I agree completely. Call me if
    you need more info on that!"  When You reply to a message Host carries
    the Subject line to the Reply Host should also carry the Msg # to the
    Reply so that the users can reference the message the reply was to.....
41    NETMAIL OPERATION...NetMail has made FIDO into a real powerhouse of a
    system.  The ability to send & receive files and messages would be a
    real asset.  A linking system with other boards, where a compound
    address would cause an automatic middle of the night transfer to
    another board.
42    Addition of "TRUE" carbon-copies of mail/msgs to multiple receivers.
43    Forwarding of messages to other receivers.
44    Return Receipt -- This would inform the SENDER of a message when the
    receipiant has RECEIVED the message that was sent.
45    Faster search scheme of messages to/from a user.  Perhaps this could be
    done using B-Trives. (what is B-Trives?)
46    How about a sysop option to dump a message to a printer?
47    More message sections!  I need at least 400 to do what I want to do
    (unlimited would be even better).


User Editing

48    Complete User editing, remote, not only to change his security level
    and time, but to actually delete user records from the userlog without
    having to run UserEdit. be able to get complete stats about any user by
    entering his name, edit any stats to reflect external contributions to
    the system.
49    Number of calls per day or total time per day configurable
50    Automatic level changes based on ul/dl ratio, excessive dl's reduce
    clearance, uploads restore clearance, this one would have to be
    configureable for ratios and whether it's in K's or # of dl's/ul's
    (or-both) and whether to include public messages as ul's/dl's
51    Along with #16 it would be nice to have two security levels per
    person, a primary # and a secondary #  (2 bytes total/user)
52    Include multiple boolean flags (per user) and allow specification of
    mask for RRHost commands. (see above as the 2nd byte adds 256 possible
    flag settings or a total of 65536 "access levels" if taken together
    with the first byte) (Note: this is already available and you use it
    every time you set a security level on a menu command)


Survey Commands

53    A survey command to read text files (nice but is it really needed since
    you can write text to screen anyway?)
54    Date stamping of survey responces
55    Time stamping of survey responces, the suggestion was that time
    stamping wasn't needed but, if you have date stamping someone will
    complain that there isn't time stamping also (probably me)
56    When saving ScratchFile information to .RES file, do NOT return to
    RRHost, but continue executing file would add to the power of Cmd #18
57    Supply variants of all branching commands that start label scan at
    current position and scan forward. Existing branches, that scan from
    beginning of file, could be replaced if the new ones wrapped on EOF,
    i.e scan current position til EOF, then BOF to current.  This would
    speed most surveys and allow more sophisticated surveys
58    Add variant of 'Write input to scratch' that does not append a CR,
    allowing multiple inputs on one line.  allow field width specification
    to preserve formatting of inputs. i.e. if a field width of 20 was
    specified, an input of 2 char. would be padded with 18 blanks while a
    20-char. input would not be padded.
59    Add special 'write control char. ' so that a TAB can be appended to the
    scratch file.
60    Add new  'Write String to Callerlog' command. If multiple CLs are
    implemented, this would generally write to the Sysop CL.
61    A. Allow for anon. surveys so that "secret ballot" votes may be taken.
    B.  Here's a toughie:  A summary file, to be used in conjunction with
    vote surveys:  Sum up all reply A, reply B, etc. and write the
    summations to a file; each time the survey is answered, add the replies
    to the ones existing in the summary, then re-write the summary to disk
    as a new file



Caller Log (System Events Log)

62    Callerlog 1) Append 'The xxx BBS is ready for callers at' at RRHost
    invocation unless 'LaunchRRH' file exists. That is, add it only on
    system boot but not Cmd#50 returns. 2) Add item to Config file so that
    Sysop can specify boot message text without patching RRHost. 3) Write
    something like 'The xxx BBS was taken offline at....' upon selection of
    'Quit' menu item. 4) Provide Sysop & User versions of Callerlog
    (Already suggested), with provisions in the Sysop version for easy
    callerlog analysis. Current 'AnalyzeCL' uses the fact that all CL
    messages within a user session start with unique 3-char. strings.
    CL analysis would be simplified if each possible message began with an
    ID code (Sysop version only). Event ID could be a simple 2-3 digit
    integer. 5) The 'sysop' CL should be as terse as possible without
    losing information, so that data can be kept for long intervals without
    using as much disk space. 6) Provide an option to display last N (maybe
    50) lines of a text file.  I have a command that allows display of the
    callerlog, and I'd like to be able to look at the end of it without
    scrolling through the whole thing.


Misc. (That could have a number of possible solutions)

63    Following the lines of a request to be able to select text on screen to
    paste to the Clipboard, I'd like to be able to scroll back through the
    display (as I can with Red Ryder) and, if I want, to select text
    through the scrolled back display (as I can with Red Ryder). Perhaps
    the sysop could set the number of screens to be remembered, as can be
    done with RR.  (I really don't see the point of this one, if the caller
    log were totally configurable it would be where to go for the record of
    what went on, and if you needed to reconstruct what a session looked
    like you could if you recorded which menu's were accessed and command
    key's used)
64    The ability (in Editors) to be able to "save" a text file with all
    fields (configurable), ie - print all fields from an entire menu, from
    the userlog, etc. Then it would be possible to enter into a custom
    dbase or whatever for manipulation - good way to document the structure
    of your board in a "readable" fashion.
65    Configurable dumping of file libraries to text (to enter into a custom
    dbase for manipulation). In this case you could then create a custom
    file with a listing of all files in all libraries for posting on the
    board. Users could download this to get a "single shot" overview of
    what is in the disparate and varied file menus.
66    DA support with all the editors in a DA format.
67    The ability to use the DAs while a user is on-line with no affect on
    the user. This would give sysops the ability to do maintanance on the
    bbs without having to take down the board.
68    66,67 won't work (that is if I understand the operating systems limits
    correctly), as under the "old" operating system as the current
    application (DA in this case) seizes control of the cpu and that would
    freeze the user out. Under the new "multi-tasking" operating system a
    seperate appl. to do maintenace would be better than a DA.  And being
    able to operate in the "multi-tasking" environment could possibly be
    the way for a Mac to support 2 lines by running Host twice and using
    both the printer & modem ports.
69    My suggestion since we would like to be able to determine not only how
    many times a file was downloaded but, how many times dl'ed between
    dates xx/xx/xx and yy/yy/yy would be a totally configureable Caller-
    Log, what messages and how they look, Tabs & CR's for loading into
    a data base (Microsoft File for example would be capable of most
    caller log analysis if messages could be configured to include tabs)